#217 Field size tweaking per RFC 2821 section 4.5.3.1

open
nobody
Database (41)
1
2010-10-15
2010-10-15
Anonymous
No

In summary, if it's an email address, it should be 320 characters, if it's a localpart, it should be 64 characters.

For table alias, the address column should be varchar(320)
for table admin, the username column should be varchar(320) for consistency
for table domain_admins, the username column should be varchar(320) for consistency
for table quota2, the username column should be varchar(320)
for table fetchmail, the username and src_user columns should be varchar(320)
for table vacation, the email column should be varchar(320)
for table log, the username column should be varchar(320)
for table quota, the username column should be varchar(320)
for table mailbox, the username column should be varchar(320), the local_part column should be varchar(64)
for table vacation_notification, the on_vacation and notified columns should be varchar(320)

doman.transport probably needs to be tweaked as well, but I've not had the opportunity to read the postfix documentation and source to determine that limit (I'm thinking max_length_transport_type + 1 (separator) + 255 (destination domain))

Discussion

  • Charles

    Charles - 2010-10-15

    If these are changed hopefully appropriate error-checking and error messages will also be provided... (I wish I could do it myself, but alas, a programmer I am not)...

     
  • Christian Boltz

    Christian Boltz - 2010-10-15
    • priority: 5 --> 1
     
  • Christian Boltz

    Christian Boltz - 2010-10-15

    Well, that's the theory/RFC.

    In practise,

    * MySQL <= 5.0.2 supports only 255 chars for varchar (http://dev.mysql.com/doc/refman/5.0/en/char.html). At the moment postfixadmin will even run on MySQL 4.x, and I don't want to change that too soon.

    * The changed fields might hit index length limits in MySQL (at least in multi-column indexes like in vacation_notification)

    * Shortening localpart to 64 chars will cause a backwards compatibility problem.
    Some very crazy people might already use a localpart with more than 64 chars - shortening the field means that those people will have a broken database (with cut-off localpart field) when upgrading postfixadmin. Sorry, that's a no-go.
    BTW: Shortening the field doesn't save space on-disk if I understand the MySQL manual right (not sure about postgres). Oh, and I think nobody cares about some bytes in the user database while users are sending tons of attachments around)

    * IMHO nobody wants a mail address longer than 255 chars - imagine how big your business card would need to be ;-) and how long you need to type the address...

    * Just tested: Postfix accepts a localpart of 400 chars.
    I didn't test a longer one, and I also didn't test with an overlong domain/subdomain, because I would have to setup this subdomain first.

    Oh, and to quote RFC 2821 section 4.5.3.1:
    Objects larger than these sizes SHOULD be avoided when
    possible. However, some Internet mail constructs such as encoded
    X.400 addresses [16] will often require larger objects: clients MAY
    attempt to transmit these, but MUST be prepared for a server to
    reject them if they cannot be handled by it.

    So if postfixadmin wants to be compatible to every crazy implementation out there, at least vacation_notification would need to use a fulltext field for the "foreign" address ;-)

    To sum it up,
    - shortening localpart to 64 chars is a no-go (backward compatibiity)
    - using 320 instead of 255 chars for mail addresses causes some problems without a (IMHO) real need
    - yeah, postfixadmin really violates the this part of the RFC ;-)

    I'll keep this bug open (because of the RFC violation), but set it on low priority. Please don't expect 320 char address fields in the near future.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks